Am 28.12.2015 um 04:14 schrieb Kenneth:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> On 12/26/2015 9:42 PM, clipka wrote:
>>
>> Where do I download version 3.7.1?
>>
> 
> I think it's here...
> 
> https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620

That would be one version that does the job, but it isn't the newest. My
recommendation would be the newest version from here:

https://github.com/c-lipka/povray/releases


> This concept of chromaticity/brightness/gamma is completely new to me (as
> regards POV-Ray rendering); ditto the new 'blend' tools in 3.7.1. Clipka will
> (hopefully!) give us more info. A question I would have is this: Are the new
> blend tools specifically for creating accurate/specialized 'color models' like
> you're doing here (as well as for your Munsell color wheel render that you
> posted earlier)-- or are the tools meant to be used for our everyday, normal
> POV-Ray scenes as well?

Those colour and pigment map blend settings are indeed intended for
everyday normal use. There are plenty of other ways to achieve what Mike
may need, so I wouldn't have implemented the feature just for him.

Instead, I'd like to give credit to Warp, who sowed the seed for this
feature back in the days when 3.7.0 was nearing completion, with his
persistent refusal to accept that "assumed_gamma 1.0" is the holy grail
of getting good images -- which of course it is, and his stubborn
position was of course entirely unfounded... except, erm... well, not quite.

As you're new to the topic of gamma, let's give you a quick overview:

- Historically, computer graphics used cathode ray tube (CRT) displays.
In a CRT the brightness of pixels on screen is controlled by modulating
a particular voltage applied to the CRT, but the resulting brightness
does not follow this voltage in a linear fashion, but according to a
power-law, i.e. brightness = voltage^gamma, where gamma is typically
somewhere around 1.8 to 2.2. To keep the display electronics and the
computer's display interface simple, neither contained any mechanism to
compensate for this distortion, so images intended to be presented on a
computer display had to be /gamma corrected/ first to take that
distortion into account. Usually this was already done during image
creation, and the image saved in a /gamma pre-corrected/ format.

- This wasn't such a bad thing though, as the human visual perception is
also highly non-linear; if we'd use an 8-bit linear brightness format,
the precision would be far too low in the dark portions of an image
(leading to visible colour banding), while being far too high in the
bright portions of an image (leading to a waste of storage space); but
it so happens that 8 bit provides just about enough precision in both
dark and bright portions of /gamma pre-corrected/ images. Thus, this
format also makes for an efficient encoding, and in modern file formats
it is therefore typically referred to as /gamma encoding/.

- In today's graphics industry, conceptually gamma pre-correction no
longer plays any role, because correcting for the specific gamma of
whatever display happens to be connected is instead done by the graphics
application, operating systems, graphics driver and/or some calibration
feature built into the display; gamma encoding still lives on however --
even in the way colour information is input or presented in user
interfaces for selecting particular colours.

- As a matter of fact, gamma pre-correction and later gamma encoding
used to be so ubiquitous in the world of computer graphics, /and/
appeared to be so natural, that for a very long time people didn't even
realize that it was there -- including the original authors of POV-Ray.
This is a problem, because POV-Ray needs to do a lot of calculations
with brightness values, and the formulae for those calculations were
written under the silent (but wrong) presumption that colour information
was encoded linearly.

- POV-Ray 3.6 was the first version of POV-Ray to ever tackle the issue
of gamma, by introducing the "assumed_gamma" keyword and the
"File_Gamma" (or was it "Display_Gamma"?) ini file setting. In this
simple model, "assumed_gamma" told POV-Ray what gamma all the input
colours were pre-corrected for, while ini file setting told POV-Ray what
gamma to pre-correct all its output for (that is file output and preview
display). However, this was essentially it -- POV-Ray still did all its
internal computations as if all colours were linear, even if
"assumed_gamma" was set to something else than 1.0. Also, setting
"assumed_gamma" to 1.0 did solve this one problem, but it required all
colours in the scene file to be specified using linear values and, worse
yet, it meant all input image files were also assumed to use linear
encoding.

- POV-Ray 3.7 solved (to my knowledge) virtually all the problems where
the 3.6 gamma handling fell short: It introduced separate ini file
settings for the two output paths (to file, and to preview display) so
that output images could be pre-corrected for a different display gamma
than the system it was previewed on; it introduced the "srgb" keyword so
that colours in the scene file could be specified in a format faimilar
to most users and easily produced by colour picker tools; and it
introduced a set of rules, as well as keywords to override them, to try
to infer the gamma for which input images are pre-corrected for.

Except for the problems that Warp still saw. His annoying feedback had
already inspired a good deal of the gamma improvements. Now he argued
that "assumed_gamma 1.0" couldn't be right because gradients would look
crappy.

He was wrong about "assumed_gamma 1.0"; it did a perfect job, and I
tried to explain why it was right.

To no avail. He was adamant that they did look crappy, and that
"assumed_gamma 2.2" did a much better job on them. Which, as I openly
admit now, and silently admitted back then, was an entirely correct
observation.

It wasn't the fault of "assumed_gamma 1.0" though, but rather the plain
fact that for artistic purposes non-linear interpolation of gradients is
desirable.

For brightness gradients, that is. When it comes to gradients between
different colours with same brightness, using that same interpolation
causes a dip in the brightness around the center of the gradient.

I tried a whole bunch of different colour models to do the interpolation
in, but none got both types of gradients right. I gave up, and 3.7 went
out the door without a solution for this problem.


Later however, I found the time to revisit the issue, and found that
good results /can/ be obtained; the key is to split up the colour
information into brightness (i.e. the weighted sum of the colour
channels) and chroma (i.e. the relative balance between the colour
channels), interpolate the brightness non-linearly and the chroma
linearly, and then re-combine the two properties into the new result colour.

That is exactly what "blend_mode 3" does: It was designed to give you
the most aesthetically pleasing gradients you could ever ask for.
"blend_mode 0" is only there for backward compatibility, "blend_mode 1"
is there to do physically correct purely linear interpolation, and
"blend_mode 2" is there just for completeness' sake.

Post a reply to this message